前言

週五碰到sql server的記憶體飆漲到90%，
找後端看了一下，看不出個所以然。
很不幸的，禮拜六又衝到95%，
只好緊急維護重開了，
禮拜一開始找問題。

正文

實際上要把記憶體操到100%，還真的很難。
試了好幾天，最多只能到97%。

然後服務都沒什麼症狀，
讓我們開始想，是不是cloudSQL真的強，
這要操下去都沒事。

再來查到cloudSQL的一篇文章，

CloudSQL的記憶體分成下面幾種

• Caches  快取
• Fixed memory  固定記憶體
• SQL Server overhead  SQL Server 開銷
• In-Memory online transactional processing (OLTP)
  記憶體中線上事務處理 (OLTP)

然後，我們得知可以更改 max server memory，
強迫SQL不要使用那麼多的記憶體。

然後，再照之前的壓測方式打下去，暴了。
確定會影響服務。

再針對 max server memory ，增加容量測試，
我們得到下面的結論。

當 Page life expectancy 這個值只要<300，
就有可能造成服務的延遲。
當掉的當下，這個值都是處於0。

Page life expectancy 表示最舊的頁面在緩衝池中停留的時間（以秒為單位），微軟建議這個值再300以上。

SELECT   [object_name],  [counter_name],  [cntr_value] FROM   sys.dm_os_performance_countersWHERE   [object_name] LIKE   '%Manager%'AND   [counter_name] = 'Page life expectancy'

我們可以同時看一下有沒有SQL處於pending狀態。

SELECT  @@SERVERNAME AS [Server Name],  RTRIM([object_name]) AS [Object Name],  cntr_value AS [Memory Grants Pending]FROM   sys.dm_os_performance_counters WITH(NOLOCK)WHERE  [object_name] LIKE   N'%Memory Manager%'  -- Handles named instancesAND   counter_name = N'Memory Grants Pending'

當這個值>0時，表示sql服務已經面臨崩潰邊緣，
該準備重啓資料庫了。

ref. Optimize high memory consumption in instances